This trigger tries to run the reward computation for each round, starting from the earliest round with the rewardConfig set. This results in a gapless history of reward data, but can potentially lead to a lot of lag and useless computation when a SV node is catching up.

We can change the whole logic for what round to process to a simple "Fetch the oldest active CalculateRewardsV2 contract, and calculate the root hash its round".

Why does this work?

• We do not need a gapless history for the reward data. We only need it for processing rewards. Once all rewards are processed, the data will still be persisted in the UpdateHistory of CalculateRewardsV2 and ProcessRewardsV2 contracts. We therefore don't expect to ever need to make the internal scan API for reward processing public.
• The reward processing trigger may read data from other scan instances if its own scan instance doesn't have the data, so we don't need to implement any backfilling:
  • When turning a CalculateRewardsV2 into a ProcessRewardsV2, we need to make sure the voting on the root hash is BFT safe. If the round is after the completeness boundary of an SV, the SV should use its own scan data. If the round is before (e.g., because the SV has just onboarded or bumped their store version), the SV will do a BFT read from other SVs to avoid deadlocking the consensus.
  • When breaking down ProcessRewardsV2 contracts, each SV may read reward data from any single other scan instead of its own. There is no BFT read required - since we have already voted on the root hash, the ProcessRewardsV2_ProcessBatch choice would immediately fail if called with malicious data. We would only have a problem if ALL nodes that computed the root hash went offline before the processing of rewards is finished.

This is all very complex, let's discuss this in our next call.